第13章テスト：早めに、こまめに、自動化

欠陥が発生したときのコストは、防止するコストを上回る。欠陥が発生したときには、対策するコストや人間関係の崩壊、ビジネスの損失などのコストも同時に発生する

XPにおいては明確なコミュニケーションで欠陥を防止し、欠陥が発生したとき場合でも対策方法を検討する

欠陥は常に存在する。想定外の状況も発生する

ビジネスにおいて経済的なダメージを受ける欠陥が避けないといけない

ウェブサイトの場合、1秒間に100件のエラーが起きても、99.9%のページで問題なければ経済的には持続可能なレベル

スペースシャトルの場合、欠陥が1件でもあれば、命に関わる

1人のチームメンバーが欠陥を起こしたとき、優れたチームではメンバー全員で解決方法を議論するで、信頼関係を構築できチーム全体で成長できる

XPではテストのコストパフォーマンスを向上させる二つの原則がある

ダブルチェック

テストコードと実装コードがイコールになることからダブルチェックと読んでいる

テストコードには理想の形を描き、実装コードはプログラミング言語に則って実装する。こうすることで、テストと実装コードの調和を保つことができる。

欠陥コスト増加（DCI: Defetct Cost Increase）

欠陥を発見するのが遅くなればなるほど、欠陥コストが大きくなる。例えば、リリース直後に発見した欠陥とリリースして1年間後に発見した欠陥では、調査するコストのレベルが変わってくる

XPではフィードバックループが短く設定するので、欠陥を発見しやすい

XPでは欠陥が発生した場合は、自動テストを書いてこまめにデプロイすることで、修正コストと欠陥の数を抑えることができる

こまめなテストには複数の意味がある

間違える可能性があるプログラマーが自身で確認することでできる。仮に、リリースしてから欠陥に気付いた場合、さまざまな人が関与することで調査コストが高くなってしまう

ペアプログラミングでテストを書くときは、同じテストケースを考えるのではなく、別々の思考プロセスからテストケースを考えることで、ダブルチェックの原則が活きてくる

ダブルチェックの原則を完全に恩恵を受けるには、プログラマー視点でのテスト（コンポーネントを徹底的にテスト）システム全体の操作に関わるテストである。

手動テストはチームのストレスが向上し、結果コーディングと手動テストの両方で間違いが増えてしまう。

静的検証はダブルチェックにおいて有効な手段。動的に変化する欠陥のテストを行うときに活きてくる。静的検証はプログラムを変更する度に実行して、即座にフィードバックを得ながら進めていかなければならない

XPではテストを書いてコードを書くことを勧めている。インターフェースと実装を分離でき、全てのテストケースを成功させることに対しての人間の欲求を満たすことができる

テストを先に書くときには、まずは1件の失敗するテストケースを書いて、解消するような実装コードを書いていく。解消したら、また1件の失敗するテストケースを書いてを繰り返していく。こうすることで、テストケースを書くとき、次に書くテストの情報を得ることが多いため。